RESTful的介绍
RESTful规范就是编写API的规范
1. REST原则
- 网络上的所有事物都被抽象为资源
- 每个资源都有一个唯一的资源标识符
- 同一个资源具有多种表现形式(xml,json等)
- 对资源的各种操作不会改变资源标识符
- 所有的操作都是无状态的
2. REST风格
- 资源 -> 网页上能看到的都是资源
- URI -> 统一资源标识符（同属理解: 身份证号）
- URL -> 统一资源定位符（同属理解: 身份证上的住址）
- 统一资源结构:
- 对资源（数据）的操作，根据HTTP请求方式（即: GET/POST/PUT/PATCH/DELETE）的不同进行不同的操作 -> 通俗理解: CBV中的根据不同的请求方式（即: GET/POST/PUT/PATCH/DELETE）调用不同的处理请求的方法
- 遵循HTTP请求方式的语义（即: 不要在处理GET请求方法中添加数据）
- 前后端传输的是资源的表述
- 前后端展现的是资源的状态
3. RESTful架构
- 凡是遵循REST风格实现的前后端交互都叫RESTful架构
- 每一个URI代表一种资源；
- 客户端和服务器之间，传递这种资源的某种表现层；
- 客户端通过HTTP请求，对服务器端资源进行操作，实现"表现层状态转化"。
4. 在 RESTful 中常用的请求方式
- GET -> 查询数据时使用
- POST -> 添加数据时使用
- PUT -> 修改数据时使用（全部修改）
- PATCH -> 修改数据时使用（局部修改）
- DELETE -> 删除数据时使用
5. 在 RESTful 中常用的状态码
- 状态码范围
- 1xx -> 信息，请求收到，继续处理。范围保留用于底层HTTP的东西，你很可能永远也用不到。
- 2xx -> 成功，行为被成功地接受、理解和采纳
- 3xx -> 重定向，为了完成请求，必须进一步执行的动作
- 4xx -> 客户端错误，请求包含语法错误或者请求无法实现。范围保留用于响应客户端做出的错误，例如。他们提供不良数据或要求不存在的东西。这些请求应该是幂等的，而不是更改服务器的状态。
- 5xx -> 范围的状态码是保留给服务器端错误用的。这些错误常常是从底层的函数抛出来的，甚至开发人员也通常没法处理，发送这类状态码的目的以确保客户端获得某种响应。当收到5xx响应时，客户端不可能知道服务器的状态，所以这类状态码是要尽可能的避免。
- 具体状态码
- 200 -> OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）
- 201 -> CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功
- 202 -> Accepted - [*]：表示一个请求已经进入后台排队（异步任务）
- 204 -> NO CONTENT - [DELETE]：用户删除数据成功
- 301 -> 临时重定向
- 302 -> 永久重定向
- 304–> 没有变化，客户端可以使用缓存数据
- 400 -> INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，确切的错误应该在error payload中描述，例如：“JSON 不合法 ”
- 401 -> Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）
- 403 -> Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的
- 404 -> NOT FOUND - [*]：未找到，指定的资源不存在
- 406 -> Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）
- 410 -> Gone -[GET]：用户请求的资源被永久删除，且不会再得到的
- 422 -> Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误，只有服务器不能处理实体时使用，比如图像不能被格式化，或者重要字段丢失。
- 500 -> INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功 -> 代码写错了
- 502 -> 网关错误
- 503 -> Service Unavailable
- 504 -> 网关超时
6. 使用和没有使用RESTfu架构的区别
- 在RESTful之前我们所定义的URL -> 一个操作就是一个接口
http://127.0.0.1/book/ -> 查看所有书籍
http://127.0.0.1/book/addbook -> 添加书籍
http://127.0.0.1/book/editbook/(\d+) -> 修改书籍
http://127.0.0.1/book/deletebook/(\d+) -> 删除数据
- 使用RESTful后 -> 统一资源结构: 根据HTTP请求方式（即: GET/POST/PUT/PATCH/DELETE）的不同进行不同的操作 -> 一个接口多个操作
http://127.0.0.1/book/ -> GET请求 查看所有数据
-> POST请求 添加书籍
http://127.0.0.1/book/(\d+) -> GET请求 查看指定的书籍
-> PUT/PATCH请求 修改书籍
-> DELETE请求 删除书籍
RESTful架构规范
1. 核心思想
- 面向资源编程
- 统一资源结构:
- 对资源（数据）的操作，根据HTTP请求方式（即: GET/POST/PUT/PATCH/DELETE）的不同进行不同的操作 -> 通俗理解: CBV中的根据不同的请求方式（即: GET/POST/PUT/PATCH/DELETE）调用不同的处理请求的方法
- 遵循HTTP请求方式的语义（即: 不要在处理GET请求方法中添加数据）
2.url规范
- url结尾不应该包含"/"
这是作为URL路径中处理中最重要的规则之一，正斜杠（/）不会增加语义值，且可能导致混淆。REST API不允许一个尾部的斜杠，不应该将它们包含在提供给客户端的链接的结尾处。
许多Web组件和框架将平等对待以下两个URI：
http://api.canvas.com/shapes/
http://api.canvas.com/shapes
但是，实际上URI中的每个字符都会计入资源的唯一身份的识别中。
两个不同的URI映射到两个不同的资源。如果URI不同，那么资源也是如此，反之亦然。因此，REST API必须生成和传递精确的URI，不能容忍任何的客户端尝试不精确的资源定位。
有些API碰到这种情况，可能设计为让客户端重定向到相应没有尾斜杠的URI（也有可能会返回301 - 用来资源重定向）。
- 在url中尽量使用名词，不要使用动词
不要使用 /book/addbook/，而是使用 /book/ 然后通过请求方式的不同调用不同的处理请求的方法，即: 在RESTful规范里不要使用之前定义url的方法
- 避免层级过深的URI
/ 在URI中表示层级，用于按实体关联关系进行对象导航，一般跟进id导航; 过深的导航容易导致url膨胀，不易维护，如 GET /zoos/1/areas/3/animals/4，尽量使用查询参数代替路径中的实体导航，如GET /animals?zoo=1&area=3;
- 体现API版本
https://v2.bootcss.com/
https://bootcss.com/v2
- 体现是否是API
https://v2.bootcss.com/api
- 有过滤条件
https://v2.bootcss.com/course?page=1
# 常见的参数
?limit=10 -> 指定返回记录的数量
?offset=10 -> 指定返回记录的开始位置。
?page_number=2&page_size=100 -> 指定第几页，以及每页的记录数。
?sortby=name&order=asc -> 指定返回结果按照哪个属性排序，以及排序顺序。
?animal_type_id=1 -> 指定筛选条件参数的设计允许存在冗余，即允许API路径和URL参数偶尔有重复。比如，GET /zoo/ID/animals 与 GET /animals?zoo_id=ID 的含义是相同的。
- 尽量使用https
3. 定义url的规范
http://127.0.0.1/book/ -> GET请求 查看所有数据
-> POST请求 添加书籍
http://127.0.0.1/book/(\d+) -> GET请求 查看指定的书籍
-> PUT/PATCH请求 修改书籍
-> DELETE请求 删除书籍
4. 返回值的规范
- 携带状态码
- 返回值
- get -> 返回查看的所有或者单条数据
- post -> 返回新增的这条数据
- put/patch -> 返回更新的这条数据
- delete -> 返回值为空
- 携带错误信息
- 携带超链接（前后端分离时很少使用，使用场景: 分页器）
← ModelForm 组件 Session →